Debugging tests or regression reports for logic designed in hardware description language (HDL) is a cumbersome process. Ability to trace method calls, event occurrences, or threads during test is valuable to debug the tests of regression reports. This kind of information can significantly shorten debug time throughout the pre-silicon verification stage. Presently, to know when or if a specific event occurred or a method was called, what the input parameters and the return value were, and who called the method, the tools are fully dependent on the existing messages written in the test code (and their verbosity) or on the usage of debugger breakpoints.
The use of messages within the test code has several disadvantages. For example, too many messages make the log file unreadable. Another disadvantage is that the quality of message depends on whether the programmer of the test code put an informative message in the method/event. Messages usually don't show internal fields values of structs, unless the debugging tool is run in interactive mode or each subfield of the struct is written separately. Another disadvantage of the use of message for debugging is that the log messages are hard to comprehend and complex to assist in determining where in the environment structure or environment code the message is located. Likewise, use of message does not inform which thread started and where or when it started.
The optional solution to the above problem is to put breakpoints throughout the code, and rerun and start debugging the code step by step or through the thread browser. This optional solution has its disadvantages. For example, debugging the code step by step via breakpoints is relevant only in interactive mode (not in regression). The optional solution requires that the test be rerun, which may waste precious time. Another disadvantage of the optional solution is that knowledge of interesting break points needs to be determined in advance, which is not always possible. For example, many times a breakpoint is placed and the code is rerun, only to find out it was the wrong place in the code to place the breakpoint and that the event of interest was missed altogether.
Another option to solving the above problem is to add debug messages to the code. This solution also has its disadvantages. For example, this solution requires knowledge beforehand about where possible problem methods are and to place debug messages for those methods. Sometimes the verification environment code (or HVL code) is locked to debuggers, and so write permissions are needed to add debug messages to the verification environment code. Another disadvantage is that the test needs to be rerun. As discussed above, too many debug messages make the log (or log file) unreadable.